home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-20
/
tn210.zip
/
NETWORK.EXE
/
NET-7.TXT
< prev
next >
Wrap
Text File
|
1992-07-02
|
8KB
|
124 lines
NET-7.TXT
NETWORK SERVERS
---------------
Continuing the packet conservation theme, let's look at the big power users,
the servers. Servers include the automated computer services such as BBSes
and lately, DXPacketClusters. The common version of TCP/IP stations are not
included in this category. Even though automated, they normally don't "serve"
the general packet population. This will undoubtedly change as the TCP/IP
code matures and networks improve.
BBS software has made giant strides since its introduction. However scant
attention has been paid to ways of practicing packet conservation with its
usage. For instance, very few users are classified as "EXPERT" on their BBS.
The advantage of an "Expert" classification is it does away with the long
alphabet soup prompt and gets the short ">" instead. Spread over time on a
busy channel, EXPERT prompts can make a significant reduction in unnecessary
packets on the frequency.
Signing onto a BBS for the first time, some BBSes only require a first name,
while others go through a lengthy registration procedure. Indeed, some BBS
software won't allow a new user to perform ANY commands until the registration
process is complete. Perhaps it's time to take another look at this to see if
anything other than a users name is ***REALLY*** vital to the BBS function.
After all, the shortening of an unnecessary registration process IS practicing
packet conservation.
A major load on the network is BBS to BBS forwarding. To the extent possible,
packet conservation can be served if SysOps insure their forwarding paths are
directed to the nearest neighbor BBS. Also, forwarding should be coordinated
among the BBS community so as to avoid forwarding to multiple BBSes in the
same general area. This will minimize sending duplicate traffic over a portion
of the network. Note here we are referring to the sending of duplicate data
over the network, not duplicate messages to a BBS.
Users should avoid the casual "DXing" of BBSes. Connecting to a distant BBS,
going through the registration process, downloading the HELP file to learn the
commands, then doing the magic "LIST" command are NO-NO's. The resulting
freight-car loads of packets will usually break the circuit, plus dump other
users. Since the local BBS is part of the national BBS forwarding network,
messages on the distant BBS are apt to be the same as found locally. Of course
there may be times one has a good reason to check out a distant BBS. But this
should be done with consideration of the possible fury such action will unleash
on the system. Practice packet conservation on a DX BBS by doing a "LL 5", for
the last five, instead of a standard "L" command which could result in dumping
100 or more, message headers onto the network. If unfamiliar with the distant
BBS commands, attempt to find the same type of BBS closer and down-load the
help file, rather than torturing the network. To this end, all BBS SysOps
could aid packet conservation by including HELP files for the different BBS
types in one of their directories.
In terms of network efficiency it could be questioned whether the BBS/node is
generally helpfull or not. Although not as bad as the TCP/IP end user class of
nodes (which don't perform anything usefull for the general packet population),
the BBS/nodes add to network overhead due to their node barf (broadcasts and
updates). If the BBS SysOp allows his node to propagate to the far end of the
network, then this encourages distant users to DX his node, thus contributing
to congestion. Most SysOps are pleased to see users on their boards, but this
type of operation can be counter-productive to the SysOp. For instance if the
SysOp uses the same portion of the network for forwarding that the distant user
is on, then the resulting congestion could cause the forwarding to be
terminated for that hour. Multiplying this type of activity with many users
and many BBSes, it's obvious that allowing BBS/nodes to propagate throughout
the network should be discouraged. Here we are referring to the BBS/Node,
rather than the gateway node portion.
KA9NNN recently released a series of notes on G8BPQ node operation and made a
similar case for BBS/nodes to either be turned off or set to not propagate
outside the immediate area. Along the same lines, some NodeOps have a policy
of not allowing BBS/nodes to network with backbone trunked LAN nodes as this
can contribute significantly to local area congestion.
As the number of VHF frequencies increase, SysOps tend to add additional ports
and radios to accomadate users. Such expansion should be carefully considered.
Throughput on adjacent channels can suffer due to receiver overload and desense
occuring when transmitters in the same band are keyed up. This may not be a
serious problem on lightly loaded channels, but with heavy activity, it could
cause an adverse network impact. Another caution is that routing confusion
may occur when multiple gateways exist within a small area. There may be
practical and political reasons why certain channels should not be gatewayed.
ALWAYS consult local network policy before proceeding with establishing
gateways or any new node.
DXclusters have recently become very popular in many parts of the country.
These operate from a PC based machine and are designed to service the DXing
community. Connected stations can report the frequency and other pertinent
information of a DX station they hear on HF to the cluster. This information
then goes out as a "spot" announcement to all other stations connected to the
cluster. The idea here is that the more "ears" monitoring for DX, the more
successful the connected stations will be in working the DX, if it's needed by
the members.
Packet clusters also provide a variety of user services. Members can obtain
beam headings to any specific DX country in the world, request WWV propagation
information, download data bases of DX related material, send and receive
messages similar to a BBS, and talk, either privately or publically to other
connected stations.
To extend their HF observer monitoring capability it is common practice for
clusters to link to each other via the VHF networks. This allows all of the
features of one cluster to be shared with other linked clusters. To prevent
connected stations from being timed out by the network nodes, short "stay
alive" messages are periodically sent in order to keep each connected user
from being disconnected.
Peak cluster usage occurs in the evenings and weekends when most of the users
are home from work. Network congestion from cluster activity can be quite
intense during these periods. Every time a cluster links to a distant cluster,
configuration and user info is shared between all of the clusters in the
linked system. A large linked cluster network can consist of 10 or more
clusters and over 100 users. Whenever a cluster link is lost, then
reestablished, a complete updating sequence is performed over the network.
When this occurs,the network impact can be quite substantial.
Because of intense DXcluster congestion, cluster SysOps in some parts of the
country have been requested to either curtail their cluster linking activity
or have been encouraged to establish their own separate cluster network.
Although separate networks may be one solution, perhaps a more satisfactory
and economical approach would be for NodeOps, TCP/IP ops, BBS and cluster
SysOps to coordinate their activites and work together toward developing an
integrated network capable of handling all of the users and servers.